The result from Requirements Engineering is a Requirements Specification. Characteristics of a good Requirements Specification are unambiguity, completeness, verifiability, consistency, modifiability, traceability, correctness and ranked for importance and/or stability.This work defines these quality attributes and answers the questions how to reach these attributes and the diffuculties which exist in this area.This work should be read to get an overwiew of the area Requirements Engineering and Requirements Specification..

According to statistics, requirements management is identified as a major source of error to failed IT-projects. Moreover communication is identified as a factor affecting the require-ments management and can lead to deficiencies in the requirements. The requirements analyst is responsible for managing the requirements from the different stakeholders, act as a com-munication accommodator and to translate abstract requirements expressed by users to more specific requirements that developers can implement. The purpose of this thesis is to study the role of the requirements analyst to investigate the problems that may arise in working with requirements management.  To achieve the purpose we have performed a requirements management process in which we ourselves took the role as the requirements analysts. The requirements management process consisted of three phases: gather requirements, document requirements and validate require-ments.

This report describes the work of developing a specification of requirements for Waste Heat Recovery Units. The main part of the paper describes how the work with the specification of requirements has been performed. One specific question to be answered is:What are the customer?s demands in case of properties for the Waste Heat Recovery Units and how is that information collected as an order documentation to suit the business area Oil & Gas?The report begins with a description of the assignment and continues with the aim and background. A theoretical part describes the different areas and methods that have been important during the process.

Requirements engineering is a widespread topic in the research field of informatics. However, there is little research regarding lack of requirements documentation and how it is perceived. The same applies for how requirements engineering in retrospect can be implemented. This is a debated issue on blogs and forums but it has not been reflected in the research area.Therefore, this study concerns research questions regarding how the developers, testers and requirements analyst experience the lack of requirements documentation and how requirements engineering in retrospect can be implemented.To answer these questions, data collection has been conducted through qualitative interviews with individuals affected by this problem in their everyday work.This study has provided an explanation of how the problem is perceived and what the consequences are, both direct and indirect. The impacts are divided into three categories and are presented as, emotional consequences, system implications and consequences regarding re source consumption.

Requirements engineering is a widespread topic in the research field of informatics. However, there is little research regarding lack of requirements documentation and how it is perceived. The same applies for how requirements engineering in retrospect can be implemented. This is a debated issue on blogs and forums but it has not been reflected in the research area.Therefore, this study concerns research questions regarding how the developers, testers and requirements analyst experience the lack of requirements documentation and how requirements engineering in retrospect can be implemented.To answer these questions, data collection has been conducted through qualitative interviews with individuals affected by this problem in their everyday work.This study has provided an explanation of how the problem is perceived and what the consequences are, both direct and indirect. The impacts are divided into three categories and are presented as, emotional consequences, system implications and consequences regarding re source consumption.

Requirements engineering is a widespread topic in the research field of informatics. However, there is little research regarding lack of requirements documentation and how it is perceived. The same applies for how requirements engineering in retrospect can be implemented. This is a debated issue on blogs and forums but it has not been reflected in the research area.Therefore, this study concerns research questions regarding how the developers, testers and requirements analyst experience the lack of requirements documentation and how requirements engineering in retrospect can be implemented.To answer these questions, data collection has been conducted through qualitative interviews with individuals affected by this problem in their everyday work.This study has provided an explanation of how the problem is perceived and what the consequences are, both direct and indirect. The impacts are divided into three categories and are presented as, emotional consequences, system implications and consequences regarding re source consumption.

Prioritisation of software requirements is a critical part of the development of software. Whichrequirements and in which order they will be developed is one of the main tasks that requirementprioritisation supports.There are different ways that a requirement prioritisation can be used, for example alone or in agroup and with different methods.The purpose of this report is to map out how you can carry out a requirement prioritisation alonewith different types of prioritisation methods and how you solve the problems that can arise whenprioritisting requirements. This is done by documenting the use of three different types of methodsthat can be execute alone. The methods are "100-dollar test", "Ranking" and "Top-tenrequirements".To be able to prioritise requirements, you need to establish which requirements you shall prioritise.The paper retrieves this information by interviewing stakeholders in the system and analysing theresult of the interviews and the execution of the requirement prioritisation.Three problems arose during that work and I present solutions on these problems. The problemswere 1) equivalent requirements when using the "100-dollar test", 2) low differentiation gradebetween the prioritised requirements in the "100-dollar test" and 3) that the requirements that wereprioritised weren't classified before the prioritisation, which leads to inaccuracies in the resultingprioritisation.The solution to the problems that the paper presents is to increase the amount of distributable unitsin the "100-dollar test" to 1000 per requirement, suggestions of classes of the requirements andthe combination of the methods "100-dollar test" and "ranking" to bypass the equivalentrequirements.The report is written in Swedish.Nyckelord: GoTRIS, requirements retrieval, requirements analysis, Viktoria Swedish ICT,requirements prioritisation, requirements, 100-dollar test, ranking, top 10 requirements..

Requirements engineering is a widespread topic in the research field of informatics. However, there is little research regarding lack of requirements documentation and how it is perceived. The same applies for how requirements engineering in retrospect can be implemented. This is a debated issue on blogs and forums but it has not been reflected in the research area.Therefore, this study concerns research questions regarding how the developers, testers and requirements analyst experience the lack of requirements documentation and how requirements engineering in retrospect can be implemented.To answer these questions, data collection has been conducted through qualitative interviews with individuals affected by this problem in their everyday work.This study has provided an explanation of how the problem is perceived and what the consequences are, both direct and indirect. The impacts are divided into three categories and are presented as, emotional consequences, system implications and consequences regarding re source consumption.

The building and plant sectors represent a large part of Sweden?s energy use. Putting energy requirements in public procurement as a tool for reducing energy consumption in the building and plant sectors is therefor an opportunity that operators can take advantage of. The aim of this thesis was to map the energy requirements in procurement that operators in the public sector use today in building and plant projects. The analysis was made with respect to if the energy requirements corresponded to the parts with large energy use in building and plant projects and also in which way energy requirements in procurement are written in the contract.

Computer use at work has risen considerably over the past fifteen years and is currently a relatively common phenomenon when 76 percent of women and 72 percent of men using the computer in their daily work (SCB Arbetsmiljörapport 2009).According to Gulliksen and Göransson (2009), Sweden is one of the countries which are more advanced in the procurement of computer systems at work. He means that Sweden has unique opportunities and conditions for user participation in the development of computer systems, when the user has the right to influence their working environment through a law in the Work Environment Act. The paper examines the importance of user involvement in system development and the Swedish company's approach and experience of user involvement. To highlight and explore the importance of user involvement, there has been a case study in which users have been representative of the development process. The case study has been conducted on a case company where the system IST analys was in need of a new interface.

This is a report for our thesis that was conducted as a conclusion of our bachelor degree in Business engineering at the Royal Institute of Technology (KTH). The work is done in cooperation with the firm Navigate Consulting Business Solutions AB.They have their leading expertise in Oracle E-Business Suite and has previously chosen to implement Oracle EBS R12. The modules that are planned to be implemented are general ledger (GL), accounts payable (AP), accounts receivable (AR), project module (PA), purchases, and CRM. For a consulting company like Navigate, it is particularly important to have a simple and effective time reporting process. We were therefore asked to provide new tabs with a decision-making process to determine if Oracle Time & Labor (OTL) is a useful time tracking system for their business.In order to achieve the company´s aim and objective we decided to follow a development method with five different phases.

The purpose of this thesis was to look at the relationship between the experiences of work related stress among male bank employees and how they dealt with potential stress. The thesis focused on male bank employee?s experiences and management of work related stress with the control requirements and support model as a starting point. Work related stress is a phenomenon that has become a serious problem with economic impact for both the individual and organizations. Increased absence from work due to medical issues is one example of such consequences.

This thesis is closely related to the Dynamically Self-Configuring Automotive System(DySCAS) project. DySCAS is a middleware for electronics in an automotive system. Thethesis work has been performed in cooperation with ENEA. Parts of the demonstrationplatform Self configurable High Availability and Policy based platform for Embeddedsystem (SHAPE) developed for the DySCAS project by ENEA have been used in theimplementation phase of this master thesis.The goal of this thesis was to evaluate how the Meteor MW, an offspring of the DySCASmiddleware, should handle QoS and to design a Quality of Service Manager (QoSM) for theMeteor MW that fulfilled hard real-time requirements. The thesis also had the objectiveof analysing and identifying the requirements on such a QoSM from a QoS perspective.Specifically the requirements to guarantee real-time support for applications running onthe MW.

This report covers the product development of a new type of extendable table for the company Karl Andersson och Söner. The company wants to expand their product collection with a new product. Karl Andersson och Söner is a well-known family company that has been located in Huskvarna since 1898, and they are producing furniture for private- and the public environment.The aim with this project is that the product should lead to increased sales, as well as expand their collection to appeal a wider audience. The work is permeated by two issues, to achieve as good results as possible. The issues will bring up how to make a table better, in terms of the competitor?s options, and how to apply a design process to develop a table that meets the markets needs and requirements.The design process of the work consists of strategically picked parts from three separate design processes.

Social work has gone from being a primarily philanthropic issue to becoming an academic discipline at university level. To ensure its legitimacy social work must be founded on, and developed through scientific research and documented experience. The purpose of this essay is to review the various arguments on social work in order to evaluate their impact on education, which in turn affects students. In addition, it will demonstrate how different forms of knowledge are valued depending on the contexts. As a means of reaching this objective, the following questions are addressed: ?What are the requirements and recommendations on how the education of social work should be structured, and why are these requirements and recommendations important??, ?How has the education of social work been influenced by the perception of valuable knowledge?? and ?How does the education of social work affect students?? The collected material consists of various arguments concerning the development of social work and the education of social work's formation.